Minutes for IBIS Quality Committee meeting. May 28, 2002 11:00am EST Adam Tambone Adam.Tambone@fairchildsemi.com *Barry Katz bkatz@sisoft.com Benjamin P Silva benjamin.p.silva@intel.com Bob Ross bob_ross@mentor.org *Eckhard Lenski Eckhard.Lenski@icn.siemens.de *Eric Brock ebrock@sisoft.com *Gregory R Edlund gedlund@us.ibm.com *Hazem Hegazy hazem_hegazy@mentorg.com John Figueroa jfigueroa@apple.com Kevin Fisher kfisher@sisoft.com *Kim Helliwell kimgh@apple.com *Lynne Green lgreen@cadence.com *Mike Labonte mlabonte@hhnetwrk.com Peter LaFlamme plaflamm@amcc.com Robert Haller rhaller@cereva.com *Roy Leventhal roy.leventhal@ieee.org Sherif Hammad sherif_hammad@mentorg.com *Todd Westerhoff twester@hhnetwk.com Tom Dagostino tom_dagostino@mentorg.com Everyone in attendance marked by * Minutes: Roll call Review of open action items: Eckhard is working on document. Kim has posted proposal for making golden parser open source. Roy briefly detailed documents created by 3com regarding model 'quality levels'. He will send a pointer to the reflector. Discussion on making golden parser open source: Main advantages. 1) More eyes looking at the code. 2) Able to port to other OS's (i.e. Macintosh) 3) Ability to view spec from different point of view. Suggested improvements. 1) Minor formatting (i.e. Background, Proposal, Conclusion, Appendix) 2) Appendix, format of proposed GPL/commercial license. Questions. 1) What does a commercial license look like? 2) Can we use existing IBIS license verbage? Main disadvantages. 1) Too many branches of the code. 2) Potential to break many EDA vendors tools. This would be a major pain with a high frequency of releases, however this issue exists today. Comments. 1) IBIS O.F. will still retain control of each release, and when they occur. 2) Could cause problems with EDA tools if we start changing what are considered 'errors' vs. 'warnings'. 3) We need to force updates to the Golden Parser, whether done as open source, or by the IBIS committee as is done today. 4) Open sourcing of s2Ibis has never worked well due to a lack of sufficent backing of a central authority. Currently controlled by NC State, but lacks a dedicated resource. (Therefore maybe not a fair comparison.) Continuing review of Checklist (Voltage levels.) Spec currently supports 13 different voltage levels. D_Overshoot_high, S_overshoot_high, Vih+, Vih-, pulse_low, vmeas+, vmeas, vmeas-, pulse_high, vil+, vil-, S_overshoot_low, D_overshoot_low. Discussion on source of voltage levels Could be a number that was actually extracted from an IO Characterization, or could be based on a spec. In checklist, Source should be documented. Discussion of application of Vmeas to receiver cells Barry reviewed how SiSoft uses Vmeas. Vmeas used for standard load measurements on output cells and timing measurements on input cells. On receivers, transitions must swing through vil/Vih thresholds, but timing is measured to Vmeas+ and Vmeas- (+/- here actually refer to min and max). It was suggested that Vmeas used for outputs only (but this is never explicitly defined in the spec.) It is clear from the spec that Vmeas iks to be used for standard load timing, but it is unclear this it is for outputs only. Need a value to use on receivers to measure timing to other than Vil, Vih. Part of the confusion here stems from the fact that the IBIS spec was not originally meant to do timing. Do we need to have Vmeas+/- on top of typ/min/max? (This will allow a guard band.) The three values that currently exist should be enough. Should we come up with a seperate set of numbers specifically for timing, or should we just clarify the current spec to make it more clear? Lets get a clarification from the IBIS Committee on what Vmeas means for a receiver. What does the Golden parser do? (Is Vmeas even allowed on an input? Yes it is!) Vmeas in model-spec section vs. model section. If it's accepted that the model section is for outputs and the model-spec section is for inputs, we could get by without adding another voltage level specifically for timing. IBIS Bird 62.6 describes DC Sessions regarding timing issues. (This one was accepted.) Need to review. Will continue the discussion on this section next time. Goals: Would like to have this checklist done by the end of the year. Hopefully ready for presentation at DesignCon. Maybe something earlier at PCB East? (October timeframe.) Next meeting will be Tuesday June 18. (Meeting postponed one week due to DAC.)